Access rights for users

Access rights for users

• Overview
• Access to data fields
• Create and logically delete objects
• Lock InstantView® messages
• Special messages for blocking functionality
• Disable Monitor-Window
• Force login - the master security object
• Locking the database for external programs
• Summary
• Examples of access rules

Overview

The ClassiX® system offers a highly differentiated system for monitoring and restricting access rights. This security system of ClassiX® is optional, it can, but does not have to be used.
However, a user can modify his database so that access is no longer possible without monitoring access rights.

The access rights are described in the core by security objects. In addition, evaluations(stored lists) of authorised users can be activated for other - unauthorised - users.

Security objects can prevent or allow the following:

• read access to a data field¹
• write access to a data field¹
• the creation of objects¹
• the logical deletion of objects¹
• access to certain parts of an application by prohibiting the messages that start that part of the application
• certain system functions such as calling up the monitor window

¹) This refers only to persistent objects from the database. For transient objects there is no control of access rights!

The security objects describing the access profile of a certain user are linked to the CX_USER object for this user and are activated at login (logged in to the ClassiX® system).
Registered security objects remain active until the next start of the ClassiX® system, they cannot be deactivated again.

Now there is still the possibility that unauthorised persons gain access to sensitive data with self-written InstantView® code.

You can also protect yourself against this. If a database contains a master security object, any unauthorised access with InstantView® instructions is impossible.

If you still want to see certain data, you have to develop your own programs in C++. If someone has the necessary means and energy, he/she can access not only the data objects but also information about the stored classes. That means this is a serious possibility to read or even modify protected data without authorization!
In the last section of this overview we show how this entrance gate can also be closed!

Access to data fields

As mentioned above, read and write access to certain data can be prevented.
The scope of such restrictions may relate to

• All objects of a class or a class derived from it (described with object CX_CLASS_SECURITY)
• all objects of exactly one class (described with object CX_CLASS_SECURITY)
• a very specific single object (described with object CX_OBJECT_SECURITY)

The information on this level firstly affects all data fields of an object, including dynamic data fields of course.

Different access rights can be assigned for certain access expressions (CX_ATTRIBUTE_SECURITY).
Objects of the class CX_ATTRIBUTE_SECURITY are always subordinate to either a CX_CLASS_SECURITY or a CX_OBJECT_SECURITY object.

The most general case of a description of read/write permissions applies to all access expressions for all objects of a certain class or classes derived from it, the most specific case concerns a very specific access expression when it is applied to a very specific individual object.

Different security objects of the classes CX_CLASS_SECURITY and CX_OBJECT_SECURITY²can be combined with an object of the class CX_SECURITY_SET. By combining general and more specific statements, access rights can often be described with only a few objects.

²) this also applies to CX_MESSAGE_SECURITY and CX_SECURITY_OPTIONS, see below CX_ATTRIBUTE_SECURITY objects never occur directly in the security set.

If the ClassiX® system checks the authorisation of an access via access printout to a certain object and a security set is active, the first element of the set decides which one is applicable for the case. If none of the security objects in the security set provides a statement, access is prohibited.

If a security object is active in the ClassiX® system, the following applies: Everything that is not explicitly allowed is prohibited!

But this is no problem: A CX_CLASS_SECURITY object for the class CX_CLASS (and derived), which allows everything, forms a background for special deviating specifications.

The order in the security set plays a role here: general statements may only come after the specific ones.
Security sets may contain further security sets as an element.

All descriptions of access rights can be represented by security objects in the correct arrangement in a security set.
As a set, you can create subgroups of certain rights and then assign a combination of such subgroups to a user in a security set that combines the subgroups.

There is another possibility: Put specializing security objects in the collection spezializations of a security object with a general statement.

It makes no difference in terms of content whether the security object_S1 describing the special cases is located in a set before the object with the general definition S0, or whether only S0 is found in the set and S0 refers to_S1 via specializations.

However, the latter method is faster. Fewer objects have to be tested,_S1 only checks if the parent object could already make a statement (see performance notes).

What happens in case of unauthorised access?

• no read access:

  InstantView® Statement	what happens
  Copy	Result ACCESS_DENIED
  Get	Result ACCESS_DENIED
  FillWindow	Window object is hidden

• no write access

  InstantView® Statement	what happens
  Put	Error message 638
  DrainWindow
  Link, Unlink (or SetReference, ClearReference, Insert, Remove)
  DeleteSlot, AssignSlot
  AdjustView	Window object is set to NON_SELECTABLE mode

The AdjustView command resets the NON_SELECTABLE state if write permissions exist.
By adjusting an input window with AdjustView before the user's input, one avoids that the final DrainWindow with error 638 can fail.

Create and logically delete objects

Permission or prohibition for this can only be given per class - with CX_CLASS_SECURITY objects.

Everything that has been said about the possibilities of combination when it comes to access to data fields also applies here.

The following InstantView® commands are affected:

Lock InstantView® messages

When a security object of the class CX_MESSAGE_SECURITY is logged on to the ClassiX® system (usually as an element of the logged on CX_SECURITY_SET object), it blocks the message.

The following InstantView® commands are affected:

It makes sense to use the TestMsg instruction to adapt the menus or buttons of an application in such a way that the affected sub-applications cannot be selected in the first place.

Special messages for blocking functionality

In some modules of the AppsWarehouse®, functionality is limited due to blocked messages.

The following messages are defined:

Disable Monitor-Window

With the monitor window, the InstantView® interpreter is available for interactive execution of commands, also with access to the objects in the database. This possibility should not be available to every user.

An object of the class CX_SECURITY_OPTIONS provides 96 bits with which special system functions can be explicitly permitted - as soon as such an object is active.

At present, only bit 0 is occupied and assigned to the start of the monitor window.

Force login - the master security object

If the database contains a master security object ( class CX_MASTER_SECURITY), this object is activated at system startup and prohibits (almost) all accesses. Only a successful login removes this lock. "Almost" all accesses means: a few functions of the classes CX_CYBER_ENTERPRISE and CX_USER can be called up so that the login can be realised with InstantView® code.

An active Master Security Object denies all write permissions and read permissions for all access paths, with one exception: The path only consists of one term (no further navigation possible and this is the call of a function which is released from the security check by a corresponding entry in the MDI.

The classes CX_CYBER_ENTERPRISE and CX_USER have such functions³:

³) Access expressions with the functions mentioned here are always accepted only by the CX_MASTER_SECURITY object. For CX_ATTRIBUTE_SECURITY, they are a normal part of an access expression, like any other function call.

With the help of these functions, login modules written with InstantView® can work even when the master security object is active.

The Login() function of the CX_USER class disables the master security object and enables security objects according to the user profile.

In addition, you can get unlimited access rights from the Master Security Object if you know the password of this object.
This allows a selected group of people to perform administrative tasks, even if they are not stored as users in the database (and that would be a prerequisite for login).

With the first request for access rights, the Master Security Object sends the system internal message MASTER_PASSWORD, with an object of the class CX_STRING on the stack.

If this message is responded to and the correct password is written into the string, the master security object allows this and all subsequent requests.

A Master Security Object can be created once in a database with the utility cxgosr.exe, and only in this way(CreatePersObject(CX_MASTER_SECURITY) does not work, of course!)

Block database for external programmes

Third party programmes are all programmes not belonging to the ClassiX® system.
Access to the database can be completely denied to all third-party programs.
Now it is also no longer possible to develop own programs with C++ to read or write in a customer's database.
This restriction can be further tightened if a customer so wishes: Only the ClassiX® system installed at the customer's site (and adapted accordingly) can access the database; any other ClassiX® installation will also become a third-party program.

Variant 1 - Block database - access only with standard ClassiX® system

• Specify the CxProtectDB.DLL in the .ini file for the ClassiX® system under DLLs:
  DLLs(..., CxProtectDB)
• Lock the database with : GetManager(OBJECT) Call(ProtectDatabases)
• At the next start of the ClassiX® system, the above mentioned DLL provides the schema keys (see documentation on ObjectStore) of the database.

Schema keys are two integer numbers. The DLL contains these numbers, but in a modified form, so you can 't find them there.


Variant 2 - Lock database - user creates own DLL with key values known only to him

• Enter your own key values in the following C++ file and compile it with the corresponding project:
  #include
  
  
   PROTECTION_KEYS(0x00000001, 0x000000002)

  The user only sees this and the header file cxProtect.hpp. Everything else is located in a static library - this C++ code is only known to ClassiX®. The result is a DLL, which differs from the above only in the other key values.

• Lock the database with : GetManager(OBJECT) Call(ProtectDatabases)
  If the database was already locked before: Start with the "old" Protection-DLL and:
  k1 k2 GetManager(OBJECT) Call(ChangeProtectionKeys)
  (k1, k2 are the keys of the "new" DLL). Then start with the new DLL.

Summary

The access to a company's data in the database of the ClassiX® system can be controlled on different levels:

Objects of class CX_MESSAGE-SECURITY control access to sub-applications.

The class CX_SECURITY_OPTIONS allows or blocks certain system functions / system options -
currently only the call of the Monitor-Window.

Examples of access rights

The structure of the access rights should consist of three parts.

The first part should consist of a default lock that must be assigned to each user or group of users. Thus, the normal user should not have access to administrative areas.
However, each user must have access to their password in order to reset it themselves.

In the second part, the specific settings of the users or user groups are configured.
Here, all module areas to which the user may not have access should be locked by the class access objects. In addition, however, all class types that the user is allowed to edit should be unlocked here, since a default access restriction of almost all classes follows in the next area.

(If conflicting access restrictions occur, the first one always applies. This allows a standard registration deadline to be defined, which can be specified by this part).

In the last part, a standard release of all classes should take place. In particular, the classes that are used everywhere in the system but do not describe a business object. These include, for example, date objects, counters, monitors and others.

Reading access should also be granted to all classes. Exceptions can be defined in one of the previous parts.